REMARKS 

This Preliminary Amendment is submitted in association with the Request For Continued 
Examination attached herewith. Claims 1-24 are currently pending. Claims 1, 2, 9, 10, 17 and 
18 are currently amended. 

I. Telephone Interview on Friday, February 4, 2005 

Applicant appreciates the courtesies extended by the Examiner in the telephone 
interview of February 4, 2005. In particular, Applicant appreciates the Examiner's willingness to 
allow amendment of the claims to correct the deficiency related to the construction of the 'or' 
structure in Claims 1, 2, 9, 10, 17 and 18, which are currently amended in a manner consistent 
with the Examiner's instructions in that telephone interview. The present amendment is 
submitted with a request for continued examination to facilitate further examination of the 
claims. 

II. Introduction to Rejections under 35 U.S.C. § 103 

In the present Office Action, Claims 1-3, 7-11, 15-19, and 23-24 are rejected under 35 
U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 5,999,971 to Buckland {Buckland) in 
view of U.S. Patent No. 5,774,660 to Brendel et al. {Brendel), Claims 10-11, 15-16, 18-19 and 
23-24 have similar limitations as Claims 2-3 and 7-8; therefore, they are rejected under the same 
rationale. Claims 4-6, 12-14, and 20-22 are rejected under 35 U.S.C. § 103(a) as unpatentable 
over Buckland and Brendel and in view of U.S. Patent No. 6,640,302 to Subramaniam et al 
{Subramaniam). Those rejections are respectfully traversed in view of the discussion made 
herein, and favorable reconsideration of the claims is requested. 

HI, The 'determining' step of exemplary Claim 1 is not taught or suggested 

First, with respect to exemplary Claim 1, Applicant respectfully submits that the cited 
combination of references does not teach or suggest Applicant's claimed feature of "determining 
whether a client's request to receive a file from one of the set consisting of the load distribution 
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server and the content server". The Examiner asserts at paragraph nine that Buckland "teaches 
. . . determining whether the client's request to receive a file from the content server originated as 
a reference from the load distribution server or as a reference from the content server itself. The 
Examiner cites the abstract of Buckland, as well as Column 2, lines 15-32, and Column 6, lines 
1-24 as teaching this functionality. The abstract of Buckland discloses: 

An apparatus for identifying a client accessing a first network site 
utilizes a control site to maintain information relating to the client. To that 
end, in response to receipt of a request from the client to access the first 
network site, it is determined if the client includes a first site data block. If 
it is determined that the client does not include the first site data block, 
then the control site is controlled to produce a control site data block 
having both control site identification data and a client identifier. The 
control site data block then is transmitted from the control site to the client 
In a similar manner, the client identifier is transmitted from the control site 
to the first network site. Upon receipt of the client identifier by the first 
network site, the first network site is controlled to transmit the first site 
data block to the client. The first site data block may have both the client 
identifier and first site identification data. 

Similarly, the text of Column 2, lines 15-32 of Buckland discloses: 

In accordance with one aspect of the invention, an apparatus for 
identifying a client accessing a first network site utilizes a control site to 
maintain information relating to the client. To that end, in response to 
receipt of a request from the client to access the first network site, it is 
determined if the client includes a first site data block. If it is determined 
that the client does not include the first site data block, then the control 
site is controlled to produce a control site data block having both control 
site identification data and a client identifier. The control site data block 
then is transmitted from the control site to the client. In a similar manner, 
the client identifier is transmitted from the control site to the first network 
site. Upon receipt of the client identifier by the first network site, the first 
network site is controlled to transmit the first site data block to the client. 
In preferred embodiments, the first site data block has both the client 
identifier and first site identification data. 

Finally, the text of Column 6, lines 1-24 of Buckland discloses: 

The process begins at step 300 in which the client 206 requests 
access to the first network site 200. Although the first network site 200 is 
discussed, the principles relating to this process can be applied to such a 
request received by any of the other network sites. Once the request is 
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received by the first network site 200, then the process continues to step 
302 in which the first network site 200 interacts with the client 206, in a 
conventional manner, to determine if the browser 210 includes a first site 
cookie (i.e., first network site data block) from the first network site 200. 
As is known in the art, the browser 210 may include a first site cookie if 
that browser 210 had accessed the first site at some earlier time and the 
first site transmitted (a/k/a "dropped") a cookie to the browser 210 for 
subsequent retrieval by the first network site 200. 

Having reviewed the cited references and amended exemplary Claim 1, Applicant 
respectfully submits that the cited texts do not teach or suggest "determining whether a client's 
request to receive a file from a content server originated as a reference from one of the set 
consisting of the load distribution server and the content server", as is recited in amended 
exemplary Claim 1. More specifically, both the first and second passage from Buckland teach 
that "it is determined if the client includes a first site data block", while the third passage teaches 
"determin[ing] if the browser 210 includes a first site cookie (i.e., first network site data block) 
from the first network site 200 ... if that browser 210 had accessed the first site at some earlier 
time". 

Applicant respectfully submits that neither of the methods disclosed in these passages 
teaches or suggests Applicant's claimed feature of "determining whether a client's request to 
receive a file from a content server originated as a reference from one of the set consisting of the 
load distribution server and the content server". Applicant respectfully submits that the feature 
recited in the cited art, of seeking a cookie from a client under the teaching of Buckland does not 
teach or suggest "determining whether a client's request to receive a file from a content server 
originated as a reference from one of the set consisting of the load distribution server and the 
content server". Applicant respectfully observes that, in cases where a client has contacted a 
server in the past and received a cookie, and then the client has bookmarked the server, the 
cookie described in the cited reference will be present without regard to whether the "client's 
request to receive a file from a content server originated as a reference from one of the set 
consisting of the load distribution server and the content server". Applicant most respectfully 
asserts that ascertaining the presence or absence of the cookie in Buckland is inadequate to 
determine, and does not suggest determining, the referring source of the request. 
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Applicant respectfully notes that, while the cookie of Buckland allows a server to know if 
it has contacted a client before, the cited references neither teach nor suggest Applicant's 
claimed feature of "determining whether a client's request to receive a file from a content server 
originated as a reference from one of the set consisting of the load distribution server and the 
content server," as is recited in exemplary Claim 1 . In view of the absence, when considering all 
of the cited references, of the recited functionality, Applicant respectfully submits that the 
rejection under 35 U.S.C. § 103 is overcome. 

IV. The 'sending' step of exemplary Claim 1 is not taught or suggested 

Still with respect to Claim 1, Applicant most respectfully submits that the cited 
combination of references does not teach or suggest Applicant's claimed feature of "responsive 
to determining that the client's request to receive the file from the content server did not originate 
as the reference from one of the set consisting of the load distribution server and the content 
server, sending to the client a file requesting that the client contact the load distribution server", 
as recited in Applicant's exemplary Claim 1. The Examiner cites the abstract of Buckland, as 
well Column 2, lines 15-32, and Column 6, lines 1-24 as teaching this functionality. The 
Examiner also cites Bremel as teaching this functionality, as is discussed below. The abstract of 
Buckland is quoted above in its entirety, but a relevant portion recites that: 

If it is determined that the client does not include the first site data 
block, then the control site is controlled to produce a control site data 
block having both control site identification data and a client identifier. 
The control site data block then is transmitted from the control site to the 
client. 

Similarly, the text of Column 2, lines 25-37 of Buckland discloses: 

The control site data block then is transmitted from the control site 
to the client. In a similar manner, the client identifier is transmitted from 
the control site to the first network site. Upon receipt of the client 
identifier by the first network site, the first network site is controlled to 
transmit the first site data block to the client. In preferred embodiments, 
the first site data block has both the client identifier and first site 
identification data. 

In some embodiments, the first network site is a World Wide Web 
site in a first network site domain, the client includes a browser, and the 
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first site data block is a cookie. The client thus may be directed to the first 
network site domain to receive the cookie from the first network site. 

The Examiner then asserts that "Buckland implicitly teaches a network site (200, 202, 
204) redirects command (read as file requesting) to client to redirect and contact control network 
site (207). The control network site implicitly read as load distribution server because it works 
the same function as receiving the redirected message from content server. . Having reviewed 
the cited references and the reasoning of the Examiner, Applicant respectfully submits that the 
cited texts do not disclose "sending to the client a file requesting that the client contact the load 
distribution server" because identification of a client and contact with a particular domain, as 
taught in the cited passages does not teach or suggest the concept of redirection to a load 
distribution server. 

More specifically, Applicant respectfully observes that both the first and second passages 
direct the control server to plant a cookie in the form of "a control site data block having both 
control site identification data and a client identifier". Applicant respectfully submits that the 
control site data block of Buckland is an identification message, not a redirect message, and that 
the true nature of the control site data block as identification is made explicit when the cited 
reference states "In a similar manner, the client identifier is transmitted from the control site to 
the first network site" (abstract, line 10). Applicant respectfully traverses the Examiner's 
assertion that the control site block serves as a redirect message because the cited texts clearly 
label the control site block as an identification message, rather than a redirect message. 
Applicant respectfully submits that the sending of an identification message, as taught in 
Buckland, does not teach or suggest Applicant's claimed feature of "sending to the client a file 
requesting that the client contact the load distribution server". 

Similarly, the Examiner has also cited Brendel as teaching Applicant's claimed feature of 
"responsive to determining that the client's request to receive the file from the content server did 
not originate as the reference from one of the set consisting of the load distribution server and the 
content server, sending to the client a file requesting that the client contact the load distribution 
server". The cited text of Brendel discloses: 
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FIG. 8 is a diagram illustrating TCP state migration of a 
connection from the load balancer to a server node. Browser 10 connects 
through Internet 66 to load balancer 70 and sends a URL request 102 once 
the connection 100 is made. Load balancer 70 does not have to be a 
separate, dedicated router or PC, and is shown as a software application 
running on server 56. Load balancer 70 can use many variations of 
balancing algorithms to determine which server 56, 51, 52 should service 
the new URL request 102. Load balancer 70 determines that the request 
should be assigned to server 52. The connection and URL request are 
migrated from load balancer 70 to server 52 using TCP state migration 
120. Server 52 accesses disk 62 to read requested file 26 and sends a copy 
of requested file 26 to browser 10 through Internet 66 as data transfer 104. 

The Examiner asserts that "Brendel, in the same field of endeavor, teaches the load 
balancer (70) does the same function as load distribution server." Upon review of the cited text 
of Brendel and the reasoning of the Examiner, and upon amendment of the relevant claim, 
Applicant respectfully submits that the reference does not disclose "responsive to determining 
that the client's request to receive the file from the content server did not originate as the 
reference from one of the set consisting of the load distribution server and the content server, 
sending to the client a file requesting that the client contact the load distribution server." First, 
the cited text does not disclose "sending to the client a file requesting that the client contact the 
load distribution server", because the cited text of Brendel discloses a client initially and directly 
contacting a load balancer. Similarly, and also for the same reason, Applicant respectfully 
submits that the cited text does not teach or disclose performing the sending step "responsive to 
determining that the client's request to receive the file from the content server did not originate as 
the reference from one of the set consisting of the load distribution server and the content 
server". In each case, Applicant respectfully submits that the cited text, which discusses a client 
directly (and without prompting) contacting a load balancer, never suggests instructing a client to 
contact a load balancer. 

Applicant respectfully observes that neither of Brendel and Buckland, nor the 
combination of Brendel and Buckland teaches or suggests Applicant's recited feature of 
"responsive to determining that the client's request to receive the file from the content server did 
not originate as the reference from one of the set consisting of the load distribution server and the 
content server, sending to the client a file requesting that the client contact the load distribution 
server." 
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Further, Applicant respectfully submits that the combination of the references does not 
suggest to one skilled in the art to modify the teachings of the references to obtain Applicant's 
claimed invention. Even if the references could be combined, as is suggested by the Examiner, 
Applicant respectfully submits that the combination of the cited texts merely discloses planting 
and seeking a cookie when a client contacts a server or a load balancer, which does not suggest 
"responsive to determining that the clients request to receive the file from the content server did 
not originate as the reference from one of the set consisting of the load distribution server and the 
content server, sending to the client a file requesting that the client contact the load distribution 
server." In view of the absence, when considering a possible combination of all of the cited 
references, of the recited functionality, Applicant respectfully submits that the rejection under 35 
U.S.C. § 103 is overcome. 

V, Arguments with respect to Claim 1 apply broadly 

Applicant respectfully submits that the rejection of exemplary Claim 1 under 35 U.S.C. § 
103 is overcome. The foregoing arguments made with respect to Claim 1 are also made with 
respect to Claims 2-8, which further limit and patentably distinguish Claim 1. The forgoing 
arguments are also made with respect to Claims 9 and 17, which claim a computer program 
product and a system for performing Applicant's invention, respectively. The foregoing 
arguments are similarly made with respect to Claims 10-16, which further limit and patentably 
distinguish Claim 9 and with respect to Claims 18-24, which further limit and patentably 
distinguish Claim 17. 

VI, The "updating" step of Applicant's Claim 4 is not taught or suggested 

With respect to exemplary Claim 4, Applicant respectfully submits that the cited 
combination of references does not teach or suggest Applicant's claimed feature of "offering in 
the file requesting that the client contact the load distribution server a means to update a 
bookmark file to include the load distribution server", as recited in Applicant's exemplary Claim 
4. The Examiner correctly notes that "Buckland and Brendel does not explicitly teach a means 
to update a bookmark file to include the load distribution server", and then cites Subramaniam, 
at Column 6, line 46- Column 8, line 28, as teaching the recited functionality. The cited text of 
Subramaniam discloses: 
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With continued reference to FIG. 1 and with reference to FIG. 2 
as well, the invention operates generally in the following manner. During 
a requesting step 120, the external client 112 requests access to data which 
is stored on the target server 104. From the perspective of the target 
server 104, this involves receiving a request during a step 200. 

By checking the IP address from which the request was made, 
communicating with the firewall software, or other familiar means, the 
target server 104 determines that the request came from outside the 
security parameter 102. Accordingly, the target server 104 does not simply 
provide the requested data. Of course, even if the request came from inside 
the security parameter 102, the target server would generally check user 
permissions against access control lists associated with the data, or take 
other steps to make sure the requesting user is entitled to access the 
requested data before providing that data. User permissions, access control 
lists, labels, and similar security controls which have a granularity smaller 
than the security perimeter 102 may continue to be used in combination 
with the security constraints described herein. 

In one embodiment, a redirector on the border server 106 redirects 
the request from the client 112 to the border server 106 during a step 122. 
The border server 106 is advertised as the target server 104. In practice, 
the border server 106 will often be on a separate machine than the target 
server 104, but those of skill in the art will appreciate that the target server 
104 and the border server 106 may also run on the same machine. The 
redirection may be accomplished using redirection capabilities which are 
part of the HTTP protocol. These redirection capabilities are 
conventionally used to automatically redirect Web browsers when a Web 
site has moved, that is, when the URL for the Web site has changed. In the 
context of the present convention, the Web site for which access is sought 
has not moved, in that the desired data still resides on the target server 
104. Instead, HTTP redirection provides a convenient and efficient tool for 
sending requests from external clients to the border server 106 to maintain 
security as described herein. 

For example, assume that the target server 104 is identified by the 
URL "http://www.Novell.com". The redirection step 122 might return the 
following URL to the external client 112: 

https://BorderManager:443?"http://www.Novell.com" (for 
authentication), or it might return the URL: 

https://BorderManager:443?"https://www.Novell.com:443" 
(authentication and force through the SSL-izer). Several things are worth 
noting in such a redirection URL signal. 
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First, the redirection signal seeks to change the protocol from 
HTTP to HTTPS. As those of skill in the art will recognize, the HTTPS 
protocol uses secure sockets layer communication. A familiar embodiment 
of secure sockets layer communication is provided by SSL software 
operating according to U.S. Pat. No. 5,825,890 assigned to Netscape 
Communications Corporation. However, as used herein the term "secure 
sockets layer communication" is not limited to SSL connections but 
instead includes any form of network communication which utilizes 
encryption in TCP/IP sockets and which is widely available in Web 
browsers and the servers with which those browsers communicate. 

Second, the redirection signal refers to the border server 106 as 
"BorderManager" in deference to the BorderManager product line from 
Novell, Inc. (BorderManager is a mark of Novell, Inc.). Those of skill in 
the art will understand that the border server 106 need not be a Novell 
BorderManager server, but need merely operate as claimed herein. 

Third, the redirection signal refers to port 443 of the border server 
106. Those of skill in the art will appreciate that other ports may also be 
used, through a port override, for instance. Moreover, redirection need not 
utilize a dedicated port; it is simply convenient in many cases to do so. 

Fourth, in its most general form, the redirection signal simply 
includes a delimited non-secure URL adjoined to a secure URL. The non- 
secure URL http://www.Novell.com identifies the target server 104, while 
the secure URL https://BorderManager identifies the border server 106. To 
conform with HTTP syntax, the non-secure UPL is delimited in the 
example redirection signal by double quotes; other delimiters may be used 
with other protocols. The non-secure URL is non-secure because it does 
not require use of a secure connection such as a secure sockets layer or 
SSL link; the secure URL is secure because it does require such a secure 
connection. 

Fifth, those of skill in the art will appreciate that directory path 
names and filenames may be appended to these examples to identify 
specific Web pages or other protected resources. For instance, the original 
request may have been for the web page which is located at 
"http://www.Novell.eom/.about.hashem/foo_desion.htm". 

Sixth, those of skill in the art will also appreciate that FTP files, 
gopher resources, and other data on the target server 104 may be handled 
in a similar manner. 

Finally, those of skill in the art will appreciate that a wide variety 
of signal field orderings, data sizes, and data encodings, and other 
variations are possible. The inventive signals may also be embodied in a 
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system in various media. For instance, they may take the form of data 
stored on a disk or in RAN memory, or the form of signals on network 
communication lines. Some embodiments will include all signal elements 
discussed above, while others omit and/or supplement those elements. 
However, the distinctive features of the invention, as set forth in the 
appended claims, will be apparent in each embodiment to those of skill in 
the art. 

During a step 124, a secure connection is formed between the 
border server 106 and the external client 112. This connection may be, for 
instance, an SSL connection formed in response to use of "https" as a 
protocol indicator in a request from the client 112 to the border server 106. 
For convenience, reference is made primarily to connections with a user of 
the external client 112. However, as noted earlier the client 112 may itself 
be a server or another node in a communications path between a user who 
is located at another machine 114 and who is seeking access to target 
server 104 data. 

Having examined the cited text, Applicant respectfully submits the words "offer", 
"update" and bookmark" do not appear in the cited text of Subramaniam, or anywhere else 
within the reference. Similarly, the words "offer", "update" and "bookmark" do not appear 
within Buckland, and Brendel does not contain the words "offer" and "bookmark". Applicant 
has likewise been unable to identify analogous concepts in the cited texts. The Examiner alleges: 

"Subramaniam teaches a redirect request sends from target server 103 
through external client 1 12 to border server 106 and has conventional capabilities 
to automatically redirect client when a web site has moved, that is, the URL for 
the web site has changed. . . It would have been obvious to one of ordinary skill in 
the art that the conventional redirect request/URL is when a user experiences a 
redirect from one page to another by asking the user to click on a link, update 
bookmark or by means of automatic redirection to a page that has change/moved 
(i.e. load distribution server. Therefore, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to combine the 
teaching of Buckland, Brendel and Subramaniam to include a means to update 
bookmark to include the load distributon server." 

Applicant respectfully submits that the Examiner has not shown any reference that 
teaches or suggests the existence of a bookmark or "a means to update a bookmark file to include 
the load distribution server". Applicant respectfully traverses the Examiner's assertion that "it 
would have been obvious to one of ordinary skill in the art at the time the invention was made to 
combine the teaching of Buckland, Brendel and Subramaniam to include" a means to update 
bookmarks. Bookmarks are mentioned in none of the cited references. Applicant respectfully 
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submits that the combination of references does not teach or suggest functionality addressed or 
suggested by none of them individually. Applicant respectfully submits that the rejection of 
Claims 4-6, 12-14, and 20-22 under 35 U.S.C. § 103 is overcome. 



VII. Conclusion 

It is respectfully submitted that the claims are in condition for allowance and favorable 
action is requested. A one month extension of time is believed to be required, and a check for 
the required fee is enclosed herewith. However, in the event that a further extension of time is 
required, please charge that extension fee and any other required fees to IBM Corporation's 
Deposit Account Number 09-0447. 



Applicant respectfully requests the Examiner contact the undersigned attorney of record 
at (512) 542-3678 if such would further or expedite the prosecution of the present Application. 

Respectfully submitted, 



Brian F. Russell 

Reg. No. 40,796 

DILLON & YUDELL, LLP 

891 1 N. Capital of Texas Highway 

Suite 2110 

Austin, Texas 78759 

(512)343-6116 

ATTORNEY FOR APPELLANT 
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